4

问题描述

翻翻别人的面试经历

这里在知乎上看到的,分享出了自己面试阿里Java岗的面试题。

clipboard.png

看了一下,除了Spring之外的其他很多题都不会,但是不能拿学校没讲Java作为借口,因为可能讲了也不会。

但是第九个问题,我觉得应该立刻话时间研究研究了,因为之前在缓存中用到了这个。

当时也不明白具体HashMapConcurrentHashMap究竟有什么区别。

clipboard.png

只是记得之前看过有关大数据的场景下利用缓存减轻数据库压力的文章,文中说常用ConcurrentHashMap,所以这里缓存就用这个了,其实并不懂原理,下面,让我们一起来研究一下。

Map

Map大家都熟悉了,Java中也有,JavaScript中也有。

Map是一种键值对类型的数据结构,根据键映射到值。

不分析源码了,就把思想给大家讲一下,以下主要以图为主。

HashMap

Java7

clipboard.png

HashMap的本质是一个可变长度的数组,在数组中每个位置保存的是一个Entry节点,该节点存储有hashkeyvaluenext等信息。

Java7中的HashMap实现与我们在数据结构中学习的类似,对key进行hash,如果冲突了,则添加到链表中。

然后查询的时候就先根据hash找到相应的位置,然后根据链表逐一比较,返回相应的value。时间复杂度取决于链表的长度,时间复杂度为O(N)

Java8

clipboard.png

Java8中对HashMap进行了优化,如果链表中元素超过8个时,就将链表转化为红黑树,以减少查询的复杂度,将时间复杂度降低为O(logN)

HashMap没有对多线程的场景下做任何的处理,不用说别的,就两个线程同时put,然后冲突了,两者需要操作一个链表/红黑树,这肯定就会有错误发生,所以HashMap是线程不安全的。

HashTable

HashTableJava7中的HashMap类似,也是一个数组加链表,不过这个线程安全。

HashTable线程安全,但是它的线程安全是依赖将所有修改HashTable的代码块都用synchronized修饰。

synchronized关键字我们之前在单例模式中用到过,它修饰的代码块,同一时刻只允许一个线程访问,其他线程会被阻塞,等待该线程执行完再执行。

所以,在HashTable中,一个线程在put,其余的线程在get的时候就会被阻塞,无法并行。所以不推荐使用HashTable,虽然它线程安全。

ConcurrentHashMap

HashMap线程不安全,HashTable性能又不好,当然需要设计一个新类去解决这些问题,这就是ConcurrentHashMap

Java7

clipboard.png

这是Java7中实现线程安全的思路,ConcurrentHashMap16segment组成,每个segment就相当于一个HashMap(数组+链表)。

segment最多16个,想要扩容,就是扩充每个segment中数组的长度。

然后只要实现每个segment是线程安全的,就让这个Map线程安全了。每个segment是加锁的,对修改segment的操作加锁,不影响其他segment的使用,所以理想情况下,最多支持16个线程并发修改segment,这16个线程分别访问不同的segment

同时,在segment加锁时,所有读线程是不会受到阻塞的。

这样设计,putget的基本操作就是先找segment,再找segment中的数组位置,再查链表。

Java8

后来人们发现Java7这样设计太复杂了,回归本质。

HashMap线程不安全的问题完全都是出在对链表/红黑树的操作上,为什么非要建一个segment加锁呢?直接对链表/红黑树加锁不就好了?

clipboard.png

所以Java8ConcurrentHashMap完全就是HashMap进行加锁,实现线程安全。

这里总结的很简单,其实源码中对这个的实现特别复杂,有兴趣的可以去看看,反正我是看着头大。

总结

  1. HashMap线程不安全。
  2. HashTable线程安全,但性能差,不推荐使用。
  3. ConcurrentHashMap线程安全。
  4. ConcurrentHashMapJava7中使用segment实现,对每个segment加锁。
  5. ConcurrentHashMapJava8中是直接在HashMap的基础上进行加锁。

参考文献:

Java7/8 中的 HashMap 和 ConcurrentHashMap 全解析
ConcurrentHashMap、HashTable、HashMap三兄弟


张喜硕
2.1k 声望423 粉丝

浅梦辄止,书墨未浓。